In recent years, there are a growing number of distributed systems that release various services via a network. Accordingly, authentication and approval of users who access such services via the network are becoming an important task to service providers on the network. When it is preferred that access to those services be granted to only a limited number of predetermined users, certificates describing authentication results or the like regarding users are often distributed to the service systems provided by the service providers to allow the users to access the services.
As the above described technique, there is a standard technique specification SAML (Security Assertion Markup Language) defined by a standardization organization OASIS for linking authentication information regarding users among providers on a network. An example of a certificate generating/distributing system using the SAML is described in Non-Patent Document 1. FIG. 1 illustrates an example of the certificate generating/distributing system described in Non-Patent Document 1. FIG. 2 illustrates an example where the certificate generating/distributing system described in Non-Patent Document 1 is applied to perform proxy access processing.
The certificate generating/distributing system described in Non-Patent Document 1 is provided with IdP (identity provider) 100, SP (service provider) 101 and user agent (software of user terminal) 102. IdP 100, SP 101 and user agent 102 are connected to each other via a network such as the Internet.
As a typical operation of the certificate generating/distributing system described in Non-Patent Document 1 having such a configuration, a procedure will be described below, which is carried out between the IdP and SP when a single sign-on is achieved through creation and distribution of an authentication certificate using an artifact profile of a Web SSO protocol.
In the example shown in FIG. 1, each user is presupposed to possess accounts for user information 103 of IdP 100 and user information 104 of SP 101 respectively. Furthermore, both accounts are linked together beforehand. That is, both accounts are stored in relation to each other. For example, when IdP 100 authenticates a user, IdP 100 transmits authentication result information to SP 101. SP 101 judges based on the received authentication result information that the user has been authenticated and provides a service (single sign-on).
As shown in FIG. 1, the user receives the authentication of IdP 100 using user agent 102 and makes a login (step S1). The user (user agent 102) then accesses SP 101 to use a service provided by SP 101 (step S2) that provides for restricted access.
SP 101 sends an authentication request message to user agent 102 for authentication of the user (step S3-a) and user agent 102 redirects (forwards) the authentication request message from SP 101 to IdP 100 (step S3-b). IdP 100 confirms that the user has already been authenticated in step S1 and creates an authentication certificate (authentication assertion) written in XML that certificates that the user has already been authenticated (step S4).
Furthermore, IdP 100 creates an artifact that plays the role of a ticket corresponding to an authentication assertion and sends the ticket back to user agent 102 (step S5-a). User agent 102 redirects the artifact to SP 101 (step S5-b). SP 101 receives the artifact, sends the artifact to IdP 100 and requests the corresponding authentication assertion (step S6). IdP 100 checks the artifact received from SP 101 and sends the corresponding authentication assertion back to SP 101 (step S7). SP 101 checks the authenticity of the authentication assertion received from IdP 100 and verifies whether or not to accept the user request for access to the service using a security policy of SP 101. When the request is accepted, SP 101 starts to provide the service to user agent 102 (step S8).
As described so far, IdP 100 creates a certificate regarding the user and distributes the certificate to SP 101. Here, as described above, the certificate distributed by IdP 100 can describe anonym information that is valid only between IdP 100 and SP 101 as information relating to the user accounts in IdP 100 and SP 101 respectively, information on the valid range (target provider validated through the distribution) of the certificate and other confidential information regarding the user or the like. That is, the certificate distributed by IdP 100 is provided with a function of preventing security information from being leaked to anybody other than the predetermined target. Non-Patent Document 1 is the document shown below.
Non-Patent Document 1: Author: OASIS, title: “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0”, medium type: online, date of posting: Mar. 15, 2005, date of search: May 30, 2007, information source: Internet <URL: http://docs.oasis-open.org/security/sam1/v2.0/sam1-core-2.0-os.pdf>